A keyboard is an example of a manual data collection device for a computer system. Typically, an operator depresses keys similar to those of a typewriter or an adding machine, and the individual keystrokes are sequentially converted by built-in switches and logic circuitry within the keyboard unit into a sequence of keyscan codes, each corresponding to the actuation of a key on the keyboard. The sequence of keyscan codes is thereafter converted into a corresponding sequence of alphanumeric (e.g., A-Z, a-z, 0-9), symbol (e.g., !, @, #, $, %) and/or function (e.g., [enter], [backspace], etc) character codes. A commonly used set of such character codes is the 7-bit ASCII (American Standard Code for Information Interchange) code, which also exists in various "extended" 8-bit versions.
In many small computer systems, including the ubiquitous "IBM-compatible personal computer", a keyboard unit transmits keyscan codes to a system unit via a keyboard port, and the system unit converts the keyscan codes to character codes which serve as input data to various user-oriented applications programs. Two sets of such keyscan codes are in common use, a "Code 1" code set typically associated with the original IBM PC and characterized by only 10 function keys and an integrated numeric/cursor keypad, and a "Code 2" code set associated with the IBM AT and characterized by 12 function keys and dedicated cursor keys.
In such a system, a programmed microprocessor inside the keyboard unit performs a number of functions, including self-test, scans the individual keys to determine their respective states, generates a keyscan code each time one of the keys changes state ("make" or "break"), stores up to 16 keyscan codes in a buffer, and transfers each keyscan code from the buffer to the system unit in accordance with a defined hand-shake protocol. Two such IBM compatible protocols are in common use, which will be referred to herein as "Mode 1" (typically associated with the IBM PC XT) and "Mode 2" (typically associated with the IBM PC AT and the IBM PS/2).
The system unit's operating system software and hardware, typically including Basic Input Output System (BIOS) firmware provided by the computer manufacturer, then converts the keyscan code signal appearing at the keyboard port into a corresponding sequence of character codes and/or status flags in a form usable by the application programs. In particular, a keyboard I/O driver (or a special purpose driver included as part of a particular application program) handles the "hand-shake" protocol used to transfer keyscan data from the keyboard unit to the computer, defines which keys are given the attributes of typematic, shift, toggle, and/or control, and updates one or more shift state flags used to process the next incoming keyscan code. The actual code and protocol used will depend on the type of computer: The most common types of keyboards are the 84 key keyboard typically used with the IBM PC XT (Code 1) and the "enhanced" 101/102 key keyboard typically associated with the IBM PC AT (Code 2). These two computer types are normally associated respectively with the two aforementioned protocols (Mode 1 and Mode 2); however, as exemplified by certain of the IBM PS/2 personal computers, it is also possible to use a Code 1 code set with a Mode 2 protocol, although most PS/2 models use the Mode 2/Code 2 combination. (In fact, the IBM PS/2 system units are typically programmed to accommodate both the Code 1 and the Code 2 keyscan code sets, as well with a third keyscan code set, known as "Code 3").
When using such an arrangement of keyboard unit and system unit, the operator may press and release the keys faster than the corresponding keyscan codes can be read (and processed into character codes) by the system unit. If the rate at which keyscan codes are entered into the keyboard buffer exceeds the rate at which the keyscan codes are removed from the buffer for transmission, the result will be a "keyboard buffer overflow" condition, which is signified to the system unit of IBM compatible computers by a special keyscan code. The system unit BIOS reacts to this special keyscan code by executing a "Beep" routine, which activates a small loudspeaker or other sound transducer inside the system unit, and thus provides the operator with an audible warning. A similar situation will also be true for the keyboards connected not directly to a system unit, but rather to a terminal connected to a remote host computer, in which case either the remote computer or built in logic within the terminal will detect a benign keyboard error condition and cause a sound transducer inside the terminal to generate a distinctive Beep. It should be noted that the keyboard buffer overflow condition is "benign" in the sense that it has no adverse influence on the operation of the computer system unit (or computer terminal), and the normal operation of the computer continues, but accompanied by an audible signal which alerts the operator to a possible corruption of input data from the keyboard.
Other data collection devices usable with computer systems and computer terminals include contact barcode readers, non-contact (e.g. laser) barcode readers, magnetic stripe readers, electrical multimeters, OCR scanners, and electronic weighing scales.
To accommodate these other types of data input devices (as well as variety of other input and output devices) a small computer typically is also provided with a serial port and the necessary software and hardware to read and write ASCII data to and from the serial port.
A keyboard emulation device may be defined as a data collection device which transmits data to a computer as keyscan codes through the computer's keyboard I/O port, but which obtains the data from a source other than actuation of physical keys on a keyboard unit by an operator. It translates the data it collects into a format acceptable to the computer operating system and transmits the data through the keyboard port according to the standard protocol for the keyboard I/O channel.
Application software created for use with manual keyboard input will thus also work with a keyboard emulator type of data collection device without any modifications to either the application program or the computer operating system. The keyboard emulator can complement or replace the keyboard unit for a given application, allowing efficient data entry. Normally, the keyboard emulator physically connects between the existing keyboard unit and computer, allowing the keyboard unit to remain active in the system, but inserting its own data into the I/O channel when data collection occurs, which may be termed a "T-connector" Mode. A "Keyboard Replacement" Mode is also possible, wherein the keyboard emulator is the only device connected to a particular keyboard port and takes over responsibility for all functions at that port. A particularly important category of keyboard emulation deVices, at least from a commercial point of view, are devices which may be plugged directly into the keyboard port of an "IBM-PC compatible" personal computer without any modifications to the system unit or to any of software used therewith.
Regardless of whether the data originates from a keyboard, from a keyboard emulation device, or from another type of data collection device, it is preferable to provide the operator with visual and/or audible feedback. One example of such feedback is the display of the characters on the computer's video monitor as they are being input from the keyboard. In addition, keyboard units are frequently provided with mechanical or electrical means to generate an audible "click" each time a key is depressed, which provides an audible form of operator feedback. In the case of ASCII data which is input via a serial port, appropriate operator feedback is sometimes provided by means of a special software driver or application program that produces the desired feedback when it detects transmission of ASCII data.
Although the ASCII character set includes a "Bell" character (ASCII 007.sub.10) which typically causes the MS-DOS operating system to generate a Beep (using the computer's built-in sound transducer) if echoed to the display device, many software programs either ignore the Bell character or treat it as just another displayable symbol ( or G). Using a special driver or application program with a keyboard emulation device is especially undesirable because it defeats its primary advantage, which is software transparency. Rather than relying on special application programs and/or device drivers (with their attendant potential incompatibility problems) to properly interpret a special control character as audible feedback, it has thus become common to provide data collection devices (other than keyboards) with a dedicated sound transducer to provide audible feedback each time the input device is activated by the operator and completes a successful operation (such as reading a barcode or other machine readable data compatible with the device). In the case of a data collection device that is intended for use with the serial port of the system unit, this may be accomplished by means of an optional module between the data collection device and the computer's serial input, which is designed to monitor the data line from the input device and produces an audible tone whenever data is being transmitted.
Prior art keyboard emulation systems often employed a sound transducer to provide audible feedback to the user or operator in the form of a beeper module. The beeper module was designed as an integral part of the keyboard emulation system; however, it added cost and bulk to the system, resulted in a product that was inconvenient to hold and/or utilized a separate chassis for the electronics (which was less desirable from an ergonomic point of view), and, since openings in the system package are needed to allow the sound to escape efficiently, compromised the mechanical integrity and sealing of the keyboard emulation system.
When inputting data both from the keyboard and from the data collection device using barcode data in accordance with a symbology (such as Code 128) that has distinct representations for upper and lower case alphabets, it is necessary to verify that any "Caps Lock" key on the associated keyboard had not been left in its "on" state before data was transmitted by the keyboard emulator to the computer. The operator could accomplish this by visually examining a "Caps Lock" indicator on the keyboard or computer screen or by visually examining the input data as displayed on the computer screen. Alternatively, some data collection devices were able to compensate for a set shift state flag automatically, presumably by monitoring all transmissions from the keyboard for Caps Lock and/or Shift keyscan codes, from which it would then be possible to deduce the current state of the shift state flag; however, such an "open loop" solution was inherently unreliable and interfered with the optimal utilization of the emulator's processing capacity.